@bors: r+

Out of curiosity, do you think it'd be feasible to CI against this? It seems like a common failure mode...

📌 Commit 644a1c9 has been approved by alexcrichton

⌛ Testing commit 644a1c9 with merge 8bd620f...

Out of curiosity, do you think it'd be feasible to CI against this? It seems like a common failure mode...

We would have to test the intrinsics on no_std targets like thumbv7m-none-eabi to catch these. That's possible with utest but quickcheck doesn't compile on no_std so we would have to add unit tests that don't depend on quickcheck specifically to test these targets. See #144.

Ideally, I'd like a much simpler test system. One that doesn't depend on compiling libgcc or compiler-rt or even quickcheck. Basically have something like this:

#[test]
fn muldi3() {
    assert_eq!(__muldi3(1, 1), 1);
    assert_eq!(__muldi3(1, 2), 2);
    assert_eq!(__muldi3(2, 3), 6);
    // ...
}

Where the assertions are randomly generated before we run the test suite. compiler-rt test suite is like this but has fixed test cases rather than randomly generated ones.

Could we perhaps have a separate project which is compatible with utest, not using quickcheck? (and then use both on CI)

Ideally, I'd like a much simpler test system.

I got a proof of concept for this system here. I have tested that it works for the x86_64-unknown-linux-gnu, armv7-unknown-linux-gnueabihf and thumbv7m-linux-eabi targets. I have only tested muldi3 and mulodi4 so far but apparently I've already found another bug in mulodi4:

thread 'mulodi4' panicked at 'attempt to subtract with overflow', /cargo/git/checkouts/compiler-builtins-ec094dc45a0179c8/644a1c9/src/int/sdiv.rs:13

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 8bd620f to master...